System for utilizing resources from multiple sources to complete a resource distribution

ABSTRACT

Embodiments of the invention are directed to systems, methods and computer program products for utilizing resources from multiple sources to complete a resource distribution. The invention may receive a distribution request from an entity, where the distribution request includes information identifying a first resource distribution device provided by a user to the entity, a first source associated with the user, and a request amount of resources. The invention may determine whether the requested amount of resources is greater than a first amount of resources in the first source, determine whether the first resource distribution device is associated with one or more other sources associated with the user, and determine whether a sum of the first amount of resources in the first source and a second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources.

FIELD OF THE INVENTION

The present invention relates to systems, computer implemented methods, and computer program products for utilizing resources from multiple sources to complete a resource distribution.

BACKGROUND OF THE INVENTION

A user may attempt to distribute resources from a source to an entity by providing the entity with information regarding the resources and the source. The entity may provide a distribution request, including the information, to a resource management entity. If the source does not have enough resources to satisfy the distribution request, the resource management entity may deny the distribution request. However, denied distribution requests consume computing resources (e.g., processing resources, memory resources, power resources, communication resources, and/or the like) and/or network resources associated with receiving information from the user, providing the distribution request to the resource management entity, processing the distribution request (e.g., by the resource management entity), notifying the entity that the distribution request is denied, and/or the like. Furthermore, after a denied distribution request, the user may attempt to distribute resources from another source to the entity, and the entity may provide another distribution request to another resource management entity. Repeated distribution requests, for a single effort to complete a resource distribution, also consume computing resources (e.g., processing resources, memory resources, power resources, communication resources, and/or the like) and/or network resources.

BRIEF SUMMARY OF THE INVENTION

The following presents a simplified summary of one or more embodiments of the invention in order to provide a basic understanding of such embodiments. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments, nor delineate the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later.

In general, embodiments of the invention are directed to systems, methods and computer program products for utilizing resources from multiple sources to complete a resource distribution. In some embodiments, a system may include a computing platform including a memory device storing a plurality of computer instructions, and at least one electronic processor (e.g., a computing processor) in communication with the memory, where the at least one electronic processor may be configured to execute the computer instructions. Based on executing the computer instructions, the system may perform one or more actions. For example, in some embodiments, the system may receive, from an entity, a distribution request including information identifying a first resource distribution device provided by a user to the entity, where the first resource distribution device is associated with a first source, and a requested amount of resources. The system may determine whether the requested amount of resources is greater than a first amount of resources in the first source. The system may determine, based on determining that the requested amount of resources is greater than the first amount of resources in the first source, whether the first resource distribution device is associated with one or more other sources associated with the user. The system may determine, based on determining that the first resource distribution device is associated with one or more other sources associated with the user, whether a sum of the first amount of resources in the first source and a second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources. The system may distribute, based on determining that the sum of the first amount of resources in the first source and the second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources, the requested amount of resources to the entity.

In some embodiments, the system may transfer, before distributing the requested amount of resources to the entity, a third amount of resources from the one or more other sources to the first source, wherein the third amount of resources is a difference between the requested amount of resources and the first amount of resources, and when distributing the requested amount of resources to the entity, distribute the requested amount of resources to the entity from the first source.

In some embodiments, the system may, when distributing the requested amount of resources to the entity, distribute the first amount of resources to the entity from the first source and distribute a third amount of resources to the entity from the one or more other sources, wherein the third amount of resources is a difference between the requested amount of resources and the first amount of resources.

In some embodiments, the system may, before distributing the requested amount of resources to the entity, request, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request, before distributing the requested amount of resources to the entity, receive, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request, and when distributing the requested amount of resources to the entity, distribute, based on receiving the authorization to utilize resources from the one or more other sources to satisfy the distribution request, the requested amount of resources to the entity.

In some embodiments, the system may distribute, based on determining that the requested amount of resources is not greater than the first amount of resources in the first source, the requested amount of resources from the first source to the entity.

In some embodiments, the system may deny, based on determining that the first resource distribution device is not associated with one or more other sources associated with the user, the distribution request.

In some embodiments, the system may deny, based on determining that the sum of the first amount of resources in the first source and the second amount of resources in the one or more other sources is not greater than or equal to the requested amount of resources, the distribution request.

In some embodiments, the system may determine, based on historical distribution requests, a likelihood of the user providing the first resource distribution device for an amount of resources greater than the first amount of resources in the first source, determine whether the likelihood satisfies a threshold, determine, based on determining that the likelihood satisfies the threshold, whether the first resource distribution device is associated with the one or more other sources associated with the user, and transfer, based on determining that the first resource distribution device is associated with the one or more other sources, a third amount of resources from the one or more other sources to the first source.

In some embodiments, the system may determine, based on the historical distribution requests, a predicted amount of resources, and wherein the third amount of resources is based on a difference between the predicted amount of resources and the first amount of resources in the first source.

The features, functions, and advantages that have been discussed may be achieved independently in various embodiments of the present invention or may be combined with yet other embodiments, further details of which can be seen with reference to the following description and drawings.

In addition to the discussed system, any of the functions, operations, or steps described herein may also be performed via a computer implemented method or via computer program product being performed by one or more computer processors.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described embodiments of the invention in general terms, reference will now be made to the accompanying drawings, where:

FIG. 1 is a schematic diagram of an exemplary embodiment of a network environment in which one or more embodiments of the present invention may operate;

FIGS. 2A and 2B are schematic diagrams of example embodiments of the present invention;

FIG. 3 is a schematic diagram of an example transaction process flow in accordance with one or more embodiments of the present invention; and

FIGS. 4 and 5 are flowcharts of exemplary methods for utilizing resources from multiple sources to complete a resource distribution in accordance with one or more embodiments of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to elements throughout. Where possible, any terms expressed in the singular form herein are meant to also include the plural form and vice versa, unless explicitly stated otherwise. Also, as used herein, the term “a” and/or “an” shall mean “one or more,” even though the phrase “one or more” is also used herein.

A “transaction” or “resource distribution” refers to any communication between a user, a financial institution, and/or another entity (e.g., a merchant) to transfer resources (e.g., funds, credit, and/or the like) for the purchasing or selling of a product. A transaction may refer to a purchase of goods or services, a return of goods or services, a payment transaction, a credit transaction, or other interaction involving a user's account. In the context of a financial institution, a transaction may refer to one or more of: a sale of goods and/or services, initiating an automated teller machine (ATM) or online banking session, an account balance inquiry, a rewards transfer, an account money transfer or withdrawal, opening a bank application on a user's computer or mobile device, a user accessing their e-wallet, or any other interaction involving the user and/or the user's device that is detectable by the financial institution. A transaction may include one or more of the following: renting, selling, and/or leasing goods and/or services (e.g., groceries, stamps, tickets, DVDs, vending machine items, and the like); making payments to creditors (e.g., paying monthly bills; paying federal, state, and/or local taxes; and the like); sending remittances; loading money onto stored value cards (SVCs) and/or prepaid cards; donating to charities; and/or the like.

In various embodiments, a point-of-transaction device (POT) may be or include a merchant machine and/or server and/or may be or include the mobile device of the user, which may function as a point of transaction device. The embodiments described herein may refer to the use of a transaction, transaction event or point of transaction event to trigger the steps, functions, routines or the like described herein. In various embodiments, occurrence of a transaction triggers the sending of a distribution request or transaction request including information identifying a resource distribution device (e.g., a payment card, such as a credit card, debit card, gift card, and/or the like, a mobile device running an electronic payment operation, such as a remote wallet, an near-field communication (NFC) based payment, and/or the like). As used herein, a “bank account” refers to a credit account, a debit/deposit account, and/or the like. Although the phrase “bank account” includes the term “bank,” the account need not be maintained by a bank and may, instead, be maintained by other financial institutions. For example, in the context of a financial institution, a transaction may refer to one or more of a sale of goods and/or services, an account balance inquiry, a rewards transfer, an account money transfer, and/or the like. A transaction may occur as a user's mobile device establishes a wireless connection, such as a W-Fi connection, with a point-of-sale terminal. In some embodiments, a transaction may include one or more of the following: purchasing, renting, selling, and/or leasing goods and/or services (e.g., groceries, stamps, tickets, DVDs, vending machine items, or the like); withdrawing cash; making payments to creditors (e.g., paying monthly bills; paying federal, state, and/or local taxes and/or bills; or the like); sending remittances; transferring balances from one account to another account; loading money onto stored value cards (SVCs) and/or prepaid cards; donating to charities; and/or the like.

In some embodiments, the transaction may refer to a technology activity such as an event and/or action or group of actions facilitated or performed by a user's device, such as a user's mobile device. Such a device may be referred to herein as a “point-of-transaction device.” A “point-of-transaction” may refer to any location, virtual location or otherwise proximate occurrence of a transaction. A “point-of-transaction device” or “resource distribution device” may refer to any device used to perform a transaction, either from the user's perspective, the merchant's perspective or both. In some embodiments, the point-of-transaction device refers only to a user's device, in other embodiments it refers only to a merchant device, and in yet other embodiments, it refers to both a user device and a merchant device interacting to perform a transaction. For example, in one embodiment, the point-of-transaction device refers to the user's mobile device configured to communicate with a merchant's point of sale terminal, whereas in other embodiments, the point-of-transaction device refers to the merchant's point of sale terminal configured to communicate with a user's mobile device, and in yet other embodiments, the point-of-transaction device refers to both the user's mobile device and the merchant's point of sale terminal configured to communicate with each other to carry out a transaction.

In some embodiments, a point-of-transaction device is or includes an interactive computer terminal that is configured to initiate, perform, complete, and/or facilitate one or more transactions. In some embodiments, a point-of-transaction device and/or a resource distribution device may be or may include any device that a user may use to perform a transaction with an entity, such as, but not limited to, an ATM, a loyalty device such as a rewards card, loyalty card or other loyalty device, a magnetic-based payment device (e.g., a credit card, debit card, or the like), a personal identification number (PIN) payment device, a contactless payment device (e.g., a key fob), a radio frequency identification device (RFID) and the like, a computer, (e.g., a personal computer, tablet computer, desktop computer, server, laptop, or the like), a mobile device (e.g., a smartphone, cellular phone, personal digital assistant (PDA) device, MP3 device, personal global positioning system (GPS) device, or the like), a merchant terminal, a self-service machine (e.g., vending machine, self-checkout machine, or the like), a public and/or business kiosk (e.g., an Internet kiosk, ticketing kiosk, bill pay kiosk, or the like), and/or various combinations of the foregoing.

Further, the term “payment credential,” “payment vehicle,” and/or “resource distribution device” as used herein, may refer to any of, but is not limited to, a physical, electronic (e.g., digital), or virtual transaction vehicle that can be used to transfer money, make a payment (for a service or good), withdraw money, redeem or use loyalty points, use or redeem coupons, gain access to physical or virtual resources, and similar or related transactions. For example, in some embodiments, the resource distribution device is a bank card issued by a bank which a customer may use to perform purchase transactions. However, in other embodiments, the resource distribution device is a virtual debit card housed in a mobile device of the customer, which can be used to electronically interact with an ATM or the like to perform financial transactions. Thus, it will be understood that the resource distribution device can be embodied as an apparatus (e.g., a physical card, a mobile device, or the like), or as a virtual transaction mechanism (e.g., a digital transaction device, digital wallet, a virtual display of a transaction device, or the like). The resource distribution device may be an unrestricted resource. Unrestricted resources, as used herein may be any resource that is not restricted for transaction. In this way, the unrestricted resources may be applied to any transaction for purchase of a product or service.

In some embodiments, an “entity” may refer to a financial institution. In some embodiments, a “financial institution” may be any organization, entity, or the like in the business of moving, investing, or lending money, dealing in financial instruments, or providing financial services. This may include commercial banks, thrifts, federal and state savings banks, savings and loan associations, credit unions, investment companies, insurance companies, and/or the like. In some embodiments, a financial institution may allow a user to establish an account with the financial institution. An “account” may be the relationship that the user has with the financial institution. Examples of accounts include a deposit account, such as a transactional account (e.g., a banking account), a savings account, an investment account, a money market account, a time deposit, a demand deposit, a pre-paid account, a credit account, a non-monetary user account that includes only personal information associated with the user, and/or the like. The account is associated with and/or maintained by the financial institution. In other embodiments, an entity may not be a financial institution. In still other embodiments, the entity may be the merchant itself. In some embodiments, the “user” may be a customer (e.g., an account holder or a person who has a third party mobile wallet system associated with his/her mobile device).

Embodiments of the invention are directed to systems, methods, and computer program products for utilizing resources (e.g., funds, credit, and/or the like) from multiple sources (e.g., accounts) to complete a resource distribution (e.g., to pay for a transaction). For a given transaction request (e.g., a distribution request), a resource management system (e.g., a system operated by a financial institution for processing payments, maintaining account balances, and/or the like) may determine whether a source (e.g., an account) associated with a resource distribution device (e.g., a payment vehicle, a credit/debit card, and/or the like) provided by a user to an entity (e.g., a merchant) to complete the transaction has enough resources to complete the transaction. In some embodiments, if the source associated with the resource distribution device does not have enough resources to complete the transaction, the resource management system may determine whether one or more other sources (e.g., other accounts) associated with the user have enough resources to complete the transaction. If the one or more other sources have enough resources to complete the transaction, the resource management system may distribute the requested amount of resources to the entity.

In this way, the resource management system may reduce a number of and/or eliminate denied distribution requests. By reducing the number of and/or eliminating denied distribution requests, the resource management system may conserve computing resources (e.g., processing resources, memory resources, power resources, communication resources, and/or the like) and/or network resources that would otherwise be consumed by receiving information from the user, providing the distribution request to the resource management entity, processing the distribution request (e.g., by the resource management entity), notifying the entity that the distribution request is denied, repeated distribution requests, and/or the like.

Additionally, or alternatively, by distributing the requested amount of resources to the entity (e.g., from the one or more other sources) even though the source does not have enough resources to complete the transaction, the resources management system may prevent the user from providing another resource distribution device (e.g., a payment vehicle, a credit/debit card, and/or the like) associated with another resource management system (e.g., another financial institution) to complete the transaction. In this way, the resource management system may ensure that the transaction is completed using the resource management system and may improve user satisfaction with the resource management system (e.g., and a financial institution maintaining the resource management system).

FIG. 1 provides a system 100 for controlling communications and interaction with a resource interaction system 118, such as merchant server system for example, which is used to process payment transactions on a network (e.g., an electronic network) or series of networks. FIG. 1 provides a unique system that includes specialized servers and system communicably linked across a distributive network of nodes required to perform the functions described herein.

The resource management system 102 generally comprises a communication device 104, a processing device 106, and a memory device 108. As used herein, the term “processing device” generally includes circuitry used for implementing the communication and/or logic functions of the particular system. For example, a processing device may include a digital signal processor device, a microprocessor device, a computing processor, and various analog-to-digital converters, digital-to-analog converters, control units, and other support circuits and/or combinations of the foregoing. Control and signal processing functions of the system are allocated between these processing devices according to their respective capabilities. The processing device may include functionality to operate one or more software programs based on computer-readable instructions thereof, which may be stored in a memory device.

The processing device 106 is operatively coupled to the communication device 104 and the memory device 108. The processing device 106 uses the communication device 104 to communicate with at least one network 116 and other devices on the network 116, such as, but not limited to a merchant server 118 (sometimes referred to herein as a resource interaction system), a point of transaction device 132, and/or a remote requesting system, such as a user device 146. As such, the communication device 104 generally comprises a modem, server, or other device for communicating with other devices on the network 116.

As further illustrated in FIG. 1, the resource management system 102 comprises computer-readable instructions 112 stored in the memory device 108, which in one embodiment includes the computer-readable instructions 112 of an application 114. In some embodiments, the memory device 108 includes data storage 110 for storing data related to the system environment, but not limited to data created and/or used by the application 114.

In one embodiment of the resource management system 102, the memory device 108 stores an application 114. In one embodiment of the invention, the application 114 may associate with applications having computer-executable program code. Furthermore, the resource management system 102, using the processing device 106 codes certain communication functions described herein. In one embodiment, the computer-executable program code of an application associated with the application 114 may also instruct the processing device 106 to perform certain logic, data processing, and data storing functions of the application. The processing device 106 is configured to use the communication device 104 to communicate with and ascertain data from one or more merchant server systems 118, point-of-transaction devices 132, and/or remote requesting system, such as a user device 146.

As illustrated in FIG. 1, the merchant server system 118 (sometimes referred to herein as a resource interaction system) is connected to the resource management system 102 via the network 116. The merchant server system includes the same types of components as the resource management system 102, namely a communication device 120, processing device 122, memory device 124, data storage 126, computer readable instructions 128, and an application 130.

The merchant server system is further equipped to communicate with various point of transaction devices 132, such as point of sale terminals at a merchant location or in a merchant's mobile vehicle or mobile location. The point of transaction devices may take various forms, but typically include the same types of components as the resource management system 102 and the merchant server system 118, namely a communication device 134, processing device 136, memory device 138, data storage 140, computer readable instructions 142, and an application 144.

Further, the merchant server system is further equipped to communicate with various user devices 146, such as mobile phones, tablets, personal computers, wearables, and the like. Again, user devices may take various forms, but typically include the same types of components as the resource management system 102 and the merchant server system 118, namely a communication device 148, processing device 150, memory device 152, data storage 154, computer readable instructions 156, and an application 158.

In some embodiments, a user (e.g., a customer) may attempt to pay for a transaction with a merchant using a card (e.g., a credit card, a debit card, and/or the like) or another payment vehicle that may be associated with (e.g., linked to) an account. For example, and as shown in an example embodiment 200 of FIG. 2A, the user may have three accounts A1, A2, and A3 and three cards C1, C2, and C3. As shown in FIG. 2A, card C1 may be associated with account A1, such that when the user provides card C1 to a merchant and the merchant attempts to process the transaction based on the card C1, funds from account A1 are used to complete the transaction. Cards C2 and C3 may be associated with and/or linked to accounts A2 and A3, respectively, in a similar manner. In the example embodiment 200 of FIG. 2A, if account A1 does not have enough funds (e.g., too low of a balance) to complete the transaction, the merchant will be notified (e.g., by a financial institution managing account A1) that the transaction cannot be completed, even if account A2 and/or account A3 has enough funds to complete the transaction. As previously noted, denied transactions (e.g., distribution requests) consume computing resources (e.g., processing resources, memory resources, power resources, communication resources, and/or the like) and/or network resources.

In some embodiments, the resource management system may permit a user to associate a card and/or payment vehicle with multiple accounts (e.g., sources). For example, and as shown in an example embodiment 250 of FIG. 2B, card C1 may be associated with account A1, A2, and A3. In some embodiments, the resource management system may include an account aggregation layer to associate a card and/or payment vehicle with multiple accounts. In the example embodiment 250 of FIG. 2B, when the user provides card C1 to a merchant and the merchant attempts to process the transaction based on the card C1, if account A1 does not have enough funds (e.g., too low of a balance) to complete the transaction, the resource management system (e.g., using the account aggregation layer) may utilize funds from account A1, account A2, and/or A3 to complete the transaction. For example, the resource management system may utilize any combination of portions of the balances of account A1, account A2, and/or account A3 to complete the transaction.

In some embodiments, the resource management system, using the account aggregation layer and/or an intelligent auto sweep in system, may execute limit checks, unauthorized access rules, other checks, and/or the like. Additionally, or alternatively, the resource management system, using the account aggregation layer and/or an intelligent auto sweep in system, may make, based on historical data, predictive transfers from other accounts so that enough funds remain in an account as described further herein.

FIG. 3 is a schematic diagram of an example transaction process flow 300 in accordance with one or more embodiments of the present invention. As shown in FIG. 3, a user 302 may initiate a resource distribution (e.g., a payment) at a transaction device 304 (e.g., which may be similar to point of transaction device 132 as shown in and described with respect to FIG. 1). For example, the user 302 may interact with the transaction device 304 using a payment vehicle (e.g., a resource distribution device).

As shown in FIG. 3, the transaction device 304 may generate a transaction request (e.g., a distribution request, a payment request, and/or the like) and transmit the transaction request to a payment gateway 306. For example, the transaction request may include information identifying the payment vehicle and a price of the transaction (e.g., a request amount of resources).

As shown in FIG. 3, the payment gateway 306 may receive the transaction request from the transaction device 304 and transmit the transaction request to a bank 308. For example, the payment gateway 306 may process the information identifying the payment vehicle, determine, based on the information identifying the payment vehicle, that the bank 308 and/or an account at the bank 308 is associated with the payment vehicle, and transmit the transaction request to the bank 308.

As shown in FIG. 3, the bank 308 may include a number of internal systems, such as an account aggregation layer 310 and a payment processing system 312. For example, the bank 308 may maintain a resource management system, and the resource management system may include one or more of the internal systems shown in FIG. 3. As further shown in FIG. 3, after the bank 308 receives the transaction request, the account aggregation layer 310 may process the transaction request (e.g., before the transaction request is sent to the payment processing system 312). For example, a resource management system, using the account aggregation layer 310, may process the transaction request in a manner similar to that described herein with respect to FIG. 2B, and in some embodiments, may transfer funds (e.g., resources) between accounts associated with the payment vehicle. In some embodiments, the resource management system, using the account aggregation layer 310, may process the transaction request in a manner similar to that described herein with respect to FIG. 4 and/or FIG. 5.

As shown in FIG. 3, the transaction request may then be transmitted to the payment processing system 312. For example, the payment processing system 312 may process the transaction request and information regarding one or more accounts associated with the payment vehicle, complete the transaction with the merchant using funds from one or more accounts associated with the payment vehicle, may notify the merchant and/or the customer that the transaction was successful or that the transaction failed, and/or the like.

As noted by the legend in FIG. 3, the interactions between the user 302, the transaction device 304, the payment gateway 306, the bank 308, the account aggregation layer 310, and the payment processing system 312 may be conducted in real time. For example, each of the interactions may occur in real time after the user 302 initiates a payment at the transaction device 304.

As shown in FIG. 3, the internal systems of the bank 308 may also include an intelligent auto sweep in system 314, an analytics system 316, a customer event hub 318, an insight engine 320, and an intent processor 322. As noted by the legend in FIG. 3, the interactions between the intelligent auto sweep in system 314, the analytics system 316, the customer event hub 318, the insight engine 320, the intent processor 322, and the payment processing system 312 may be conducted as a predictive batch. For example, each of the interactions may occur in a predictive manner before the user 302 initiates a payment at the transaction device 304 and/or as soon as the user 302 initiates a payment at the transaction device 304.

In some embodiments, the analytics system 316 may provide input, such as customer specific thresholds, for the intelligent auto sweep in system 314. For example, the analytics system 316 may analyze a count of sweep-ins (e.g., a number of times the account aggregation layer and/or the intelligent auto sweep in system transfers money between accounts of a user to complete a transaction) for a user's accounts and/or for one or more interlinked accounts. In some embodiments, if the count of sweep-ins has reached above a threshold set by the user, then the analytics system 316 may provide a stop flag to the intelligent auto sweep in system 314 to stop automatic movement of resources (e.g., funds) from one account to another. Additionally, or alternatively, the user may set a threshold limit on an amount to be transferred into an interlinked account, and the analytics system 316 may provide such a threshold limit to the intelligent auto sweep in system 314. In some embodiments, the analytics system 316 may provide input to the intelligent auto sweep in system 314 based on historical transactions, accounts owned by the user, accounts owned by friends and/or family, and/or the like.

In some embodiments, the customer event hub 318 may include a repository of historical events (e.g., transactions, resource distributions, and/or the like) associated with one or more users (e.g., customers), one or more accounts (e.g., sources), one or more merchants (e.g., entities), one or more payment vehicles (e.g., resource distribution devices), and/or the like, which may collectively be referred to as customer historical transaction data. For example, the customer event hub 318 may include data regarding the user, historical transactions associated with the user, one or more accounts associated with the user, one or more merchants associated with the user, one or more payment vehicles associated with the user, and/or the like. As shown in FIG. 3, the customer event hub 318 may provide the customer historical transaction data to the insight engine 320.

In some embodiments, the insight engine 320 may generate insights (e.g., based on the historical transaction data) for historical events. For example, to generate the insights, the insight engine 320 may analyze and/or extract meaningful information from the customer historical transaction data (e.g., from the customer event hub 318) by identifying patterns in the customer historical transaction data. As shown in FIG. 3, the insight engine 320 may provide the insights, patterns, and/or the like to the intent processor 322.

In some embodiments, the intent processor 322 may determine, based on the insights, patterns, and/or the like from the insight engine 320, a probability of a particular event occurring in the near future. Additionally, or alternatively, the intent processor 322 may determine a predicted transaction amount (e.g., a price, an amount of a resource distribution, how much money may be required, and/or the like) for the particular event. For example, the intent processor 322 may determine, based on a customer purchasing (e.g., booking) a one-way flight, a probability that the customer may purchase a return flight, a taxi ride, and/or the like. In some embodiments, the intent processor 322 may determine, based on determined probabilities for one or more events, a near future intent (e.g., a predicted future transaction), and determine, based on historical data and/or the like, a predicted transaction amount for the near future intent. As shown in FIG. 3, the intent processor 322 may provide the near future intent and/or the predicted transaction amount to the intelligent auto sweep in system 314.

In some embodiments, the intelligent auto sweep in system 314 may determine, based on the predicted transaction amount, if an account (e.g., account A1) does not have enough funds (e.g., too low of a balance) to complete the predicted future transaction. Additionally, or alternatively, the intelligent auto sweep in system 314 may transfer funds from one or more other accounts associated and/or interlinked with the account (e.g., account A2 and/or A3) to the account, such that, after the transfer, the account has enough funds to complete the predicted future transaction. For example, the resource management system, using the intelligent auto sweep in system 314, may utilize any combination of portions of the balances of account A1, account A2, and/or account A3 to achieve an amount of funds in account A1 to complete the predicted future transaction.

In some embodiments, the intelligent auto sweep in system 314 may transfer funds based on parameters (e.g., to prevent an excessive number of transfers). For example, the parameters may include event types, transaction categories, a time to reverse, a confidence factor, and/or the like.

The event types (e.g., of the predicted future transaction) may include temporary events and life events. For example, life events may include birthdays, anniversaries, and/or the like around or on which the resource management system may expect transactions, and the intelligent auto sweep in system 314 and/or the account aggregation layer 310 may ensure that funds are available in one or more accounts associated with a user before the actual transaction initiates. The transaction categories (e.g., of the predicted future transaction) may include travel, household, recurring, and/or the like.

The time to reverse may be a number of hours that pass after an amount is transferred from a first account to a second account before the amount is transferred back to the first account from the second account if the amount is not used by the second account. For example, if the resource management system, using the intelligent auto sweep in system 314 and/or the account aggregation layer 310, transfers an amount from account A2 and/or A3 to account A1 and the amount remains unutilized in account A1 for a number of hours defined by the time to reverse, the resource management system, using the intelligent auto sweep in system 314 and/or the account aggregation layer 310, may transfer the amount from account A1 back to account A2 and/or A3.

The confidence factor may be a confidence that the predicted future transaction will occur. In some embodiments, if the resource management system, using the intelligent auto sweep in system 314 and/or the account aggregation layer 310, transfers an amount from a first account to a second account and the amount is utilized from the second account, the confidence factor may increase. Additionally, or alternatively, if the resource management system, using the intelligent auto sweep in system 314 and/or the account aggregation layer 310, transfers an amount from a first account to a second account and the amount is not utilized from the second account, the confidence factor may decrease.

FIG. 4 is a flowchart of an exemplary method 400 for utilizing resources from multiple sources to complete a resource distribution (e.g., using a book transfer architecture) in accordance with one or more embodiments of the present invention. In some embodiments, a resource management system, such as the resource management system described herein with respect to FIGS. 1-3, and/or internal systems of a financial institution may perform the method 400.

As shown in FIG. 4, the method 400 may include a customer swiping a card C1 at a point-of-sale (e.g., a point of transaction device, a merchant's store, and/or the like) or performing an online transaction using card C1 (block 402). The method 400 may further include determining whether a balance in account A1, associated with card C1, is too low to complete a transaction initiated by the customer (block 404). If the balance in account A1 is not too low, the method 400 may include completing the transaction from account A1 (block 406) and sending a message of the transaction status to the customer (block 408).

As shown in FIG. 4, if the balance in account A1 is too low, the method 400 may include determining if the card C1 is interlinked (block 410). If the card C1 is not interlinked, the method 400 may include denying the transaction such that the transaction fails (block 412) and sending a message of the transaction status to the customer (block 408).

As shown in FIG. 4, if the card C1 is interlinked, the method 400 may include determining and/or checking one or more balances in other interlinked accounts, such as accounts A2 and A3 (block 414). The method 400 may include determining whether balances of accounts A2 and/or A3 are high enough to complete the transaction (block 416). If the balances of accounts A2 and/or A3 are not high enough to complete the transaction, the method 400 may include denying the transaction such that the transaction fails (block 412) and sending a message of the transaction status to the customer (block 408).

As shown in FIG. 4, if the balances of accounts A2 and/or A3 are high enough to complete the transaction, the method 400 may include sending a message to the customer to confirm an interlink transaction (block 418) (e.g., as a check to prevent unauthorized transactions). If the customer rejects the interlink transaction, the method 400 may include denying the transaction such that the transaction fails (block 412) and sending a message of the transaction status to the customer (block 408).

As shown in FIG. 4, if the customer confirms the interlink transaction, the method 400 may include transferring funds (e.g., distributing resources) from account A2 and/or A3 to account A1 (block 420). The method 400 may include crediting an amount in account A1 and debiting the amount from account A2 and/or A3 (block 422). The method 400 may include completing the transaction from account A1 (block 424) and sending a message of the transaction status to the customer (block 408).

As noted above, the method 400 of FIG. 4 is merely an example, and other methods in accordance with the present invention may include additional steps, fewer steps, and/or other steps.

FIG. 5 is a flowchart of an exemplary method 500 for utilizing resources from multiple sources to complete a resource distribution (e.g., using a multi-account usage architecture) in accordance with one or more embodiments of the present invention. In some embodiments, a resource management system, such as the resource management system described herein with respect to FIGS. 1-3, and/or internal systems of a financial institution may perform the method 500.

As shown in FIG. 5, the method 500 may include a customer swiping a card C1 at a point-of-sale (e.g., a point of transaction device, a merchant's store, and/or the like) or performing an online transaction using card C1 (block 502). The method 500 may further include determining whether a balance in account A1, associated with card C1, is too low to complete a transaction initiated by the customer (block 504). If the balance in account A1 is not too low, the method 500 may include completing the transaction from account A1 (block 506) and sending a message of the transaction status to the customer (block 508).

As shown in FIG. 5, if the balance in account A1 is too low, the method 500 may include determining if the card C1 is interlinked (block 510). If the card C1 is not interlinked, the method 500 may include denying the transaction such that the transaction fails (block 512) and sending a message of the transaction status to the customer (block 508).

As shown in FIG. 5, if the card C1 is interlinked, the method 500 may include determining and/or checking one or more balances in other interlinked accounts, such as accounts A2 and A3 (block 514). The method 500 may include determining whether balances of accounts A2 and/or A3 are high enough to complete the transaction (block 516). If the balances of accounts A2 and/or A3 are not high enough to complete the transaction, the method 500 may include denying the transaction such that the transaction fails (block 512) and sending a message of the transaction status to the customer (block 508).

As shown in FIG. 5, if the balances of accounts A2 and/or A3 are high enough to complete the transaction, the method 500 may include sending a message to the customer to confirm an interlink transaction (block 518) (e.g., as a check to prevent unauthorized transactions). If the customer rejects the interlink transaction, the method 500 may include denying the transaction such that the transaction fails (block 512) and sending a message of the transaction status to the customer (block 508).

As shown in FIG. 5, if the customer confirms the interlink transaction, the method 500 may include performing the transaction from account A1, A2, and/or A3 (e.g., using portions of funds, resources, and/or the like from account A1, A2, and/or A3) and linking the transaction with card C1 (block 520). The method 500 may include completing the transaction from account A1, A2, and/or A3 (block 522) and sending a message of the transaction status to the customer (block 508).

As noted above, the method 500 of FIG. 5 is merely an example, and other methods in accordance with the present invention may include additional steps, fewer steps, and/or other steps.

As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as an apparatus (including, for example, a system, a machine, a device, a computer program product, and/or the like), as a method (including, for example, a business process, a computer-implemented process, and/or the like), or as any combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely software embodiment (including firmware, resident software, micro-code, and the like), an entirely hardware embodiment, or an embodiment combining software and hardware aspects that may generally be referred to herein as a “system.” Furthermore, embodiments of the present invention may take the form of a computer program product that includes a non-transitory, computer-readable storage medium having computer-executable program code portions stored therein. As used herein, a processor may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more special-purpose circuits perform the functions by executing one or more computer-executable program code portions embodied in a computer-readable medium, and/or having one or more application-specific circuits perform the function. As such, once the software and/or hardware of the claimed invention is implemented the computer device and application-specific circuits associated therewith are deemed specialized computer devices capable of improving technology associated with selective authorization of resource usage based on geographic positioning and usage category information associated with a resource interaction system.

It will be understood that any suitable computer-readable medium may be utilized. The computer-readable medium may include, but is not limited to, a non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, infrared, electromagnetic, and/or semiconductor system, apparatus, and/or device. For example, in some embodiments, the non-transitory computer-readable medium includes a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), and/or some other tangible optical and/or magnetic storage device. In other embodiments of the present invention, however, the computer-readable medium may be transitory, such as a propagation signal including computer-executable program code portions embodied therein.

It will also be understood that one or more computer-executable program code portions for carrying out the specialized operations of the present invention may be required on the specialized computer include object-oriented, scripted, and/or unscripted programming languages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL, Python, Objective C, and/or the like. In some embodiments, the one or more computer-executable program code portions for carrying out operations of embodiments of the present invention are written in conventional procedural programming languages, such as the “C” programming languages and/or similar programming languages. The computer program code may alternatively or additionally be written in one or more multi-paradigm programming languages, such as, for example, F#.

It will further be understood that some embodiments of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of systems, methods, and/or computer program products. It will be understood that each block included in the flowchart illustrations and/or block diagrams, and combinations of blocks included in the flowchart illustrations and/or block diagrams, may be implemented by one or more computer-executable program code portions. These one or more computer-executable program code portions may be provided to a processor of a special purpose computer for the authorization and instant integration of credit cards to a digital wallet, and/or some other programmable data processing apparatus in order to produce a particular machine, such that the one or more computer-executable program code portions, which execute via the processor of the computer and/or other programmable data processing apparatus, create mechanisms for implementing the steps and/or functions represented by the flowchart(s) and/or block diagram block(s).

It will also be understood that the one or more computer-executable program code portions may be stored in a transitory or non-transitory computer-readable medium (e.g., a memory, and the like) that can direct a computer and/or other programmable data processing apparatus to function in a particular manner, such that the computer-executable program code portions stored in the computer-readable medium produce an article of manufacture, including instruction mechanisms which implement the steps and/or functions specified in the flowchart(s) and/or block diagram block(s).

The one or more computer-executable program code portions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus. In some embodiments, this produces a computer-implemented process such that the one or more computer-executable program code portions which execute on the computer and/or other programmable apparatus provide operational steps to implement the steps specified in the flowchart(s) and/or the functions specified in the block diagram block(s). Alternatively, computer-implemented steps may be combined with operator and/or human-implemented steps in order to carry out an embodiment of the present invention.

While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations and modifications of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein. 

What is claimed is:
 1. A system for utilizing resources from multiple sources, said system comprising: a computing platform comprising a memory device storing a plurality of computer instructions, and at least one electronic processor in communication with the memory device, wherein the at least one electronic processor is configured to execute the computer instructions to: receive, from an entity, a distribution request comprising: information identifying a first resource distribution device provided by a user to the entity, wherein the first resource distribution device is associated with a first source; and a requested amount of resources; determine whether the requested amount of resources is greater than a first amount of resources in the first source; determine, based on determining that the requested amount of resources is greater than the first amount of resources in the first source, whether the first resource distribution device is associated with one or more other sources associated with the user; determine, based on determining that the first resource distribution device is associated with one or more other sources associated with the user, whether a sum of the first amount of resources in the first source and a second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources; distribute, based on determining that the sum of the first amount of resources in the first source and the second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources, the requested amount of resources to the entity; transfer, before distributing the requested amount of resources to the entity, a third amount of resources from the one or more other sources to the first source, wherein the third amount of resources is a difference between the requested amount of resources and the first amount of resources; and when distributing the requested amount of resources to the entity, distribute the requested amount of resources to the entity from the first source.
 2. The system according to claim 1, wherein said at least one electronic processor is configured to execute the computer instructions to, when distributing the requested amount of resources to the entity: distribute the first amount of resources to the entity from the first source; and distribute a third amount of resources to the entity from the one or more other sources, wherein the third amount of resources is a difference between the requested amount of resources and the first amount of resources.
 3. The system according to claim 1, wherein said at least one electronic processor is configured to execute the computer instructions to: before distributing the requested amount of resources to the entity, request, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request; before distributing the requested amount of resources to the entity, receive, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request; and when distributing the requested amount of resources to the entity, distribute, based on receiving the authorization to utilize resources from the one or more other sources to satisfy the distribution request, the requested amount of resources to the entity.
 4. The system according to claim 1, wherein said at least one electronic processor is configured to execute the computer instructions to: distribute, based on determining that the requested amount of resources is not greater than the first amount of resources in the first source, the requested amount of resources from the first source to the entity.
 5. The system according to claim 1, wherein said at least one electronic processor is configured to execute the computer instructions to: deny, based on determining that the first resource distribution device is not associated with one or more other sources associated with the user, the distribution request.
 6. The system according to claim 1, wherein said at least one electronic processor is configured to execute the computer instructions to: deny, based on determining that the sum of the first amount of resources in the first source and the second amount of resources in the one or more other sources is not greater than or equal to the requested amount of resources, the distribution request.
 7. The system according to claim 1, wherein said at least one electronic processor is configured to execute the computer instructions to: determine, based on historical distribution requests, a likelihood of the user providing the first resource distribution device for an amount of resources greater than the first amount of resources in the first source; determine whether the likelihood satisfies a threshold; determine, based on determining that the likelihood satisfies the threshold, whether the first resource distribution device is associated with the one or more other sources associated with the user; and transfer, based on determining that the first resource distribution device is associated with the one or more other sources, a third amount of resources from the one or more other sources to the first source.
 8. The system according to claim 7, wherein said at least one electronic processor is configured to execute the computer instructions to: determine, based on the historical distribution requests, a predicted amount of resources, and wherein the third amount of resources is based on a difference between the predicted amount of resources and the first amount of resources in the first source.
 9. A computer implemented method for selective authorization of resource usage based on geographic positioning and usage category information associated with a resource interaction system, said computer implemented method comprising: receiving, from an entity using a computing processor via an electronic network, a distribution request comprising: information identifying a first resource distribution device provided by a user to the entity, wherein the first resource distribution device is associated with a first source; and a requested amount of resources; determining, using a computing processor via an electronic network, whether the requested amount of resources is greater than a first amount of resources in the first source; determining, using a computing processor via an electronic network, based on determining that the requested amount of resources is greater than the first amount of resources in the first source, whether the first resource distribution device is associated with one or more other sources associated with the user; determining, based on determining that the first resource distribution device is associated with one or more other sources associated with the user, using a computing processor, and via an electronic network, whether a sum of the first amount of resources in the first source and a second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources; distributing, based on determining that the sum of the first amount of resources in the first source and the second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources, using a computing processor, and via an electronic network the requested amount of resources to the entity; transferring, before distributing the requested amount of resources to the entity, a third amount of resources from the one or more other sources to the first source, wherein the third amount of resources is a difference between the requested amount of resources and the first amount of resources; and wherein distributing the requested amount of resources to the entity comprises distributing the requested amount of resources to the entity from the first source.
 10. The method according to claim 9, wherein distributing the requested amount of resources to the entity comprises: distributing the first amount of resources to the entity from the first source; and distributing a third amount of resources to the entity from the one or more other sources, wherein the third amount of resources is a difference between the requested amount of resources and the first amount of resources.
 11. The method according to claim 9, comprising: before distributing the requested amount of resources to the entity, requesting, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request; before distributing the requested amount of resources to the entity, receiving, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request; and wherein distributing the requested amount of resources to the entity comprises distributing, based on receiving the authorization to utilize resources from the one or more other sources to satisfy the distribution request, the requested amount of resources to the entity.
 12. The method according to claim 9, comprising: distributing, based on determining that the requested amount of resources is not greater than the first amount of resources in the first source, the requested amount of resources from the first source to the entity.
 13. The method according to claim 9, comprising: denying, based on determining that the first resource distribution device is not associated with one or more other sources associated with the user, the distribution request.
 14. The method according to claim 9, comprising: denying, based on determining that the sum of the first amount of resources in the first source and the second amount of resources in the one or more other sources is not greater than or equal to the requested amount of resources, the distribution request.
 15. The method according to claim 9, comprising: determining, based on historical distribution requests, a likelihood of the user providing the first resource distribution device for an amount of resources greater than the first amount of resources in the first source; determining whether the likelihood satisfies a threshold; determining, based on determining that the likelihood satisfies the threshold, whether the first resource distribution device is associated with the one or more other sources associated with the user; and transferring, based on determining that the first resource distribution device is associated with the one or more other sources, a third amount of resources from the one or more other sources to the first source.
 16. The method according to claim 15, comprising: determining, based on the historical distribution requests, a predicted amount of resources, and wherein the third amount of resources is based on a difference between the predicted amount of resources and the first amount of resources in the first source.
 17. A computer program product comprising computer program code stored on a non-transitory computer-readable medium, said computer program product used for utilizing resources from multiple sources, said computer program code comprising computer instructions to cause one or more control units to perform the following operations: receiving, from an entity using a computing processor via an electronic network, a distribution request comprising: information identifying a first resource distribution device provided by a user to the entity, wherein the first resource distribution device is associated with a first source; and a requested amount of resources; determining, using a computing processor via an electronic network, whether the requested amount of resources is greater than a first amount of resources in the first source; determining, using a computing processor via an electronic network, based on determining that the requested amount of resources is greater than the first amount of resources in the first source, whether the first resource distribution device is associated with one or more other sources associated with the user; determining, based on determining that the first resource distribution device is associated with one or more other sources associated with the user, using a computing processor, and via an electronic network, whether a sum of the first amount of resources in the first source and a second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources; distributing, based on determining that the sum of the first amount of resources in the first source and the second amount of resources in the one or more other sources is greater than or equal to the requested amount of resources, using a computing processor, and via an electronic network the requested amount of resources to the entity transfer, before distributing the requested amount of resources to the entity, a third amount of resources from the one or more other sources to the first source, wherein the third amount of resources is a difference between the requested amount of resources and the first amount of resources; and when distributing the requested amount of resources to the entity, distribute the requested amount of resources to the entity from the first source.
 18. The computer program product according to claim 17, wherein said computer program code comprises computer instructions to cause one or more control units to perform the following operations: before distributing the requested amount of resources to the entity, requesting, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request; before distributing the requested amount of resources to the entity, receiving, from the user, authorization to utilize resources from the one or more other sources to satisfy the distribution request; and wherein distributing the requested amount of resources to the entity comprises distributing, based on receiving the authorization to utilize resources from the one or more other sources to satisfy the distribution request, the requested amount of resources to the entity. 